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DETAILED ACTION * 
Status of Claims \ 1 

1 . Claims 1-26, and 28 are pending in the Application. 

Claims 1, 3, 4, 6, 11, 12, 14-17 19, 20, 23, 24 and 28 have been amended. H 
Claim 27 remains canceled. 
Claims 1-26, and 28 are rejected. 

Response to Amendment 

2. Applicant's amendments and arguments filed on 30 April 2007 in response to the 
office action mailed on 31 January 2007 have been fully considered, but they are not 

persuasive. Therefore, the rejections made in the previous office action are maintained, 

I ■} 

and restated below, with changes as needed to address the amendments. 

Claim Rejections - 35 USC § 103 M 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

3. Claims 1-13, 15-26, and 28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Dunham (US Patent 6,269,431 B1 ), in further view of Manley et al. , j 
(US PG Publication 2003/01 82325 A1 ), hereinafter Manley. i 
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As for claim 1, Dunham teaches an apparatus for managing incremental storage, 
the apparatus comprising: 

a policy management module (host - Fig. 1 , element 20) configured to set 
a storage management policy for storage capacity of a backup virtual volume 
(secondary storage - Fig. 1 , element 29), wherein the backup virtual volume is ; j 
configured to store storage data from an storage operation on a primary volume and the 
virtual volume comprises at least one volume of a storage pool (col. 19, lines 36-47 - 
the storage pool comprises at least one secondary and virtual volume). , |^j 

a storage pool management module (backup agent - Fig. 1 , element 25) 
configured to monitor available storage capacity of the backup virtual volume and to 
change the storage capacity of the backup virtual volume in response to the storage 
management policy and the available storage capacity (the backup agent responds to a 
request made by the host for a backup routine (i.e. change in storage capacity). The 
backup agent monitors the capacity by checking if any spare storage is available - Fig. 
1 5 flow chart, col. 21 , lines 1 6-63), wherein changing the storage capacity comprise iif 
dynamically allocating and de-allocating a storage volume of the virtual volume to thej 1 
backup virtual volume in response to the change to the storage capacity (Fig. 15, if a 
spare volume is available, the next virtual volume will be assigned to it - col. 21 , linesMi 
16-63). Note additionally Dunham teaches de-allocating volumes in the storage after 
modification access - col. 6, line 33 through col. 7, line 17; and 

an incremental log (secondary directory - Fig. 1 , element 28) 
corresponding to the backup virtual volume, the incremental log configured to map a 
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virtual address of the backup virtual volume assigned to the incremental storage data: to . 
a physical storage address of the at least one storage volume of the virtual volume (col. 
7, line 18 through col. 8, line 15 and Fig. 10 - secondary directory is responsible for j, ^ 
appending information to a file (i.e. log) to track and map information stored in the 
storage pool). 

Despite these teachings Dunham (including virtual backup volumes), he fails to 
specifically teach incremental snapshots (i.e. storage) as claimed by Applicant, rather 
he teaches performing a full backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which » 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074 j :i 
all lines). 

It would have been obvious to one of ordinary skill in the art at the time of the |r*f ' 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 

As for claims 12 and 24, Dunham teaches a method (and medium comprising 
code configured) for managing incremental storage, the method (and code) comprising 
(configured to): ! \ 
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monitoring available storage capacity of the backup virtual volume and to 
change the storage capacity of the backup virtual volume in response to the 
storage management policy and the available storage capacity (the backup agent 
responds to a request made by the host for a backup routine (i.e. change in 
storage capacity). The backup agent monitors the capacity by checking if any 
spare storage is available - Fig. 15 flow chart, col. 21, lines 16-63), wherein the 
backup virtual volume is configured to store incremental storage data from an 
incremental storage operation of a primary volume and the backup virtual volume 
comprises at least one storage volume of a storage pool, the at least one storage 
volume allocated to the backup virtual volume (col. 19, lines 36-47 - the storage 
pool comprises at least one secondary and virtual volume). 

dynamically allocating and de-allocating a storage volume of the storage 
pool to the backup virtual volume in response to the change to the storage 
capacity of the backup virtual volume (Fig. 15, if a spare volume is available, the , 

next virtual volume will be assigned to it - col. 21 , lines 16-63. Note additionally 

I r] 

Dunham teaches de-allocating volumes in the storage after modification access - 
col. 6, line 33 through col. 7, line 17 - more specifically, one the data is written, ... 
the capacity is no longer available, hence it is deallocated); and 

mapping an incremental log (secondary directory - Fig. 1 , element 28) 
corresponding to the virtual volume a virtual address, assigned to the incremental 
storage data to a physical storage address of the at least one storage volume of 
the storage pool (col. 7, line 18 through col. 8, line 15 and Fig. 10 - secondary 
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! ! 

directory is responsible for appending information to a file (i.e. log) to track and 
map information stored in the storage pool). : 
Despite these teachings (including virtual backup volumes), Dunham fails to 
specifically teach incremental snapshots (i.e. storage) as claimed by Applicant, rather 
he teaches performing a full backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). H 
It would have been obvious to one of ordinary skill in the art at the time of ] 
the invention for Dunham to further include Manley's asynchronous mirroring of 
snapshots into his own virtual storage system. By doing so, Dunham have a r*^ 
more efficient snapshot mechanism, capable of only storing and transferring data 
that has been modified, rather than performing a full backup as taught by Manley 
in paragraph 0015, all lines. 

As for claim 16, Dunham teaches a system for managing incremental storage, 
the system comprising: 

a primary volume (col. 19, lines 36-47 describes at least one primary and 

I'! 

virtual volume); 

a baseline volume configured to store a baseline backup copy of data on i 
the primary volume (Fig. 1 , element 29 - secondary storage); 
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a storage pool with at least one storage volume (secondary storage - Fig. 
1 , element 29) configured to store incremental storage data from an incremental storage 
operation of the primary volume in response to changes in data stored on the primary 
volume after storing the baseline backup copy on the baseline volume, where the 

i ■! 

storage volume is allocated as a backup virtual volume (col. 19, lines 36-47 - the 
storage pool comprises at least one secondary and virtual volume). Referring to Fig. 
15, the host instructs the backup agent to allocate storage area volumes during required 
for the backup operation; 

a policy management module (host - Fig. 1 , element 20) configured to set 
a storage management policy for storage capacity of the backup virtual volume 
(secondary storage - Fig. 1 , element 29); 

a storage pool management module (backup agent - Fig. 1 , element 25) 
configured to monitor available storage capacity of the backup virtual volume and to . ^ 
change the storage capacity of the backup virtual volume in response to the storage j 
management policy and the available storage capacity (the backup agent responds to a 
request made by the host for a backup routine (i.e. change in storage capacity). The , 
backup agent monitors the capacity by checking if any spare storage is available - Fig. 
15 flow chart, col. 21, lines 16-63), wherein changing the storage capacity comprise 
dynamically allocating and de-allocating a storage volume of the storage pool to the 
backup virtual volume in response to the change to the storage capacity (Fig. 15, if a 
spare volume is available, the next virtual volume will be assigned to it - col. 21 , lines 
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.16-63). Note additionally Dunham teaches de-allocating volumes after modification' W 

access - col. 6, line 33 through col. 7, line 17; and 

an incremental log (secondary directory - Fig. 1 , element 28) 
corresponding to the backup virtual volume, the incremental log configured to 
map a virtual address of the backup virtual volume assigned to the incremental 
storage data to a physical storage address of the at least one storage volume of 
the virtual volume (col. 7, line 18 through col. 8, line 15 and Fig. 1.0 - secondary 
directory is responsible for appending information to a file (i.e. log) to track and 
map information stored in the storage pool). I 
. Despite these teachings (including backup virtual volumes), Dunham fails to 

specifically teach incremental snapshots (i.e. storage) as claimed by Applicant, rather 

he teaches performing a full backup. 

Manley however discloses a system and method for asynchronous mirroring of 

snapshots at a destination using a purgatory directory and inode mapping in which 

incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 

alllines). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 
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As for claim 23, Dunham teaches an apparatus for managing incremental 
storage, the apparatus comprising: 

means for monitoring available storage capacity of a backup virtual j , 
volume and to change the storage capacity of the backup virtual volume in 
response to the storage management policy and the available storage capacity^ 
(the backup agent responds to a request made by the host for a backup routine 
(i.e. change in storage capacity). The backup agent monitors the capacity by 
checking if any spare storage is available - Fig. 1 5 flow chart, col. 21 , lines 1 6- 
63), wherein the backup virtual volume is configured to store incremental storage 
data from an incremental storage operation on a primary volume and the backup 
virtual volume comprises at least one storage volume of a storage pool, the at 
leats one storage volume allocated to the backup virtual (col. 19, lines 36-47 - ; ! 
the storage pool comprises at least one secondary and virtual volume). | : j 

means for dynamically allocating and de-allocating a storage volume of 
the storage pool to the backup virtual volume in response to the change to the Ml 
storage capacity of the backup virtual volume (Fig. 15, if a spare volume is 
available, the next virtual volume will be assigned to it - col. 21 , lines 16-63. 
Note additionally Dunham teaches de-allocating volumes in the storage after 
modification access - col. 6, line 33 through col. 7, line 17) - col. 19, lines 36-47 
- the storage pool comprises at least one secondary and virtual volume; and 

means for mapping an incremental log (secondary directory - Fig. 1 , 
element 28) corresponding to the backup virtual volume a vjrtual address, 
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assigned to the incremental storage data to a physical storage address of the at 
least one storage volume of the storage pool (col. 7, line 18 through col. 8, line 
15 and Fig. 10 - secondary directory is responsible for appending information to 
a file (i.e. log) to track and map information stored in the storage pool). 
Despite these teachings (including backup virtual volumes), Dunham fails to 

specifically teach incremental snapshots (i.e. storage) as claimed by Applicant, rather 

he teaches performing a full backup. 

Manley however discloses a system and method for asynchronous mirroring of 

snapshots at a destination using a purgatory directory and inode mapping in which . 

incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 

all lines). 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, j 

all lines. , 

;•! 

As for claim 28, Dunham teaches a method for deploying a computer readable 
medium for managing incremental storage, the method comprising: 

determining customer requirements for incremental storage (Fig. 1, 
element 23 - the user (i.e. customer) inputs the backup requirements via the host, 
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element 20). This input helps the system to determine the specifics of backup required i4 
by said user; i ;| 

i 

deploying a storage management program for managing incremental storage, the 
storage management program comprising (the backup agent's operations are 
deployed via the backup software (Fig. 1 , element 224)) 

monitoring available storage capacity of a backup virtual volume and to change 

♦ 

the storage capacity of the incremental backup virtual volume in response to the 
storage management policy and the available storage capacity (the backup agent 
responds to a request made by the host for a backup routine (i.e. change in storage 
capacity). The backup agent monitors the capacity by checking if any spare storage 
is available - Fig. 15 flow chart, col. 21, lines 16-63), wherein the backup virtual 
volume is configured to store incremental storage data from an incremental storage : 
operation of a primary volume and the backup virtual volume comprises at least one 
storage volume of a storage pool, the at least one storage volume allocated to the 
backup virtual volume (col. 19, lines 36-47 - the storage pool comprises at least one 
secondary and virtual volume). 

dynamically allocating and de-allocating a storage volume of the 
storage pool to the backup virtual volume in response to the change to the 
storage capacity of the backup virtual volume (Fig. 1 5, if a spare volume is 
available, the next virtual volume will be assigned to it - col. 21 , lines 1 6- 

! "ft 

63. Note additionally Dunham teaches de-allocating volumes after 
modification access - col. 6, line 33 through col. 7, line 17) - col. 19, lines * 
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36-47 - the storage pool comprises at least one secondary and virtual 
volume; and 

mapping an incremental log (secondary directory - Fig. 1 , element 
28) corresponding to the backup virtual volume a virtual address of the 
backup virtual volume, assigned to the incremental storage data to a 
physical storage address of the at least one storage volume of the storage 
pool (col. 7, line 1 8 through col. 8, line 1 5 and Fig. 1 0 - secondary 
directory is responsible for appending information to a file (i.e. log) to track, . 
and map information stored in the storage pool), and; 
maintaining the storage management program (col. 15, lines 32-54 - the 
backup program can be reprogrammed and loaded via a floppy disk). 

Despite these teachings (including backup virtual volumes), Dunham fails to 
specifically teach incremental snapshots (i.e. storage) as claimed by Applicant, rather , 
he teaches performing a full backup. 

Manley however discloses a system and method for asynchronous mirroring of q 
snapshots at a destination using a purgatory directory and inode mapping in which ^ 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). v 
It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient 
snapshot mechanism, capable of only storing and transferring data that has been 



9 
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modified, rather than performing a full backup as taught by Manley in paragraph 001 3, ! 
all lines. 

As for claim 2, Dunham teaches the physical storage address as comprising a ! 
volume identifier (col. 6, lines 33-63, the pointer points to each physical unit (i.e. the 
directory intrinsically stores information to identify the address of the data stored in the 
memory, with the corresponding physical volume)). 

As for claim 3, Dunham teaches the storage pool management module as being 
further configured to allocated and de-allocate a portion of a storage volume to backup 
virtual volume (Fig. 15, if a spare volume is available, the next virtual volume will be 
assigned to it - col. 21 , lines 16-63. Note additionally Dunham teaches de-allocating 

! i 
.i 

volumes after modification access - col. 6, line 33 through col. 7, line 17), wherein the 
storage pool comprises at least one storage volume allocated as a virtual volume (col. 
19, lines 36-47 - the storage pool comprises at least one secondary and virtual 
volume). 

As for claims 4, 15 and 26, Dunham teaches the apparatus (method and 
medium) as further comprising a read module configured to read data stored in the 
backup virtual volume by way of a data path independent from a data path used to store 
the storage data (Fig. 2, each host (31 , 32, 33) can read data from each storage system 
via a plurality of paths (i.e. through the ring network (30)). More specifically, each host 

can communicate either with the secondary storage device either directly, or indirectly 

I i 

via either of the two data storage subsystems) 
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As for claim 5, Dunham teaches the storage management module as allocating 
and de-allocating storage volumes without user input (once the backup policy is set, the 
host communicates with the backup agent irrespective of the user input in order to 
effectively manage and backup the volumes (Fig. 15)). i 4 

As for claim 6, Dunham teaches the storage pool management module as beirjg y 
further configured to allocate a second storage volume to the backup virtual volume in 
response to a reduction in available space on a first storage volume (Fig. 15, more M 
volumes will be allocated to create sufficient memory to store the copied data), 

As for claims 7 and 8, Dunham teaches the storage pool as comprising a RAID 
storage array (col. 9, lines 34-53). 

As for claim 9, Dunham teaches the incremental log as comprising a lookup table 
(the directory is used by the system to look up the correspondence between physical 
and virtual addresses - col. 7, line 18 through col. 8, line 15). 

As for claim 10, Dunham teaches the storage pool management module as 
further configured to increase the storage capacity in response to the available storage i 
capacity increasing above a first storage capacity threshold and to decrease the storage 
capacity in response to the available storage capacity decreasing below a second ' ^ 
storage capacity threshold (Fig. 1 5, the allocation and de-allocation is dynamically 
determined based on available storage capacity). 

As for claim 11, Dunham teaches the storage pool management module as being 
further configured to de-allocate storage volumes wherein the de-allocated storage 
volumes are available for allocation to a virtual volume unrelated to the backup virtual 

! 4 
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volume (referring to Fig. 2, the plurality of data storage subsystems allows for the de- 



allocation of memory within one of the subsystems. The de-allocated data may at a 
later time be reallocated, just not to a storage area within the other subsystems storage 
pools). 

As for claims 13 and 25, Dunham teaches providing incremental snapshot data 
of the primary volume in response to a replication operation (col. 5, lines 57 through col. 
6, line 6 - the snapshot operation is performed in response to the backup operation). 

As for claim 17, Dunham teaches a replication module configured to transmit the f 
incremental data from the primary volume to the storage pool (Fig. 3, element 56 - the 
remote link adapter is used to transmit data from the primary storage subsystem to the 
secondary backup virtual volume (i.e. within the storage pool)). . ^ 

As for claim 19, Dunham teaches: 



elements 59-62); 

the backup virtual volume comprises a backup virtual volume corresponding to 
each primary volume, each backup volume comprising at least one storage volume of 
the storage pool (the secondary storage area stores backup data of the primary volume 
in order to maintain a copy of the data that corresponds to the data stored in the primar^l 
volumes); j > 

the incremental log comprising an incremental log corresponding to each backup 
virtual volume (col. 7, line 18 through col. 8, line 15); and * | f H*f 




■(li- 



the primary volume comprising a plurality of primary volumes (Fig. 3, 
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the storage pool management module monitors available capacity of each 
backup virtual volume and allocates and de-allocates storage volumes for each backup 
virtual volume from the storage pool (the backup agent responds to a request made by l ' 
the host for a backup routine (i.e. change in storage capacity). The backup agent | ;>:i 
monitors the capacity by checking if any spare storage is available - Fig. 15 flow chart, 
col. 21, lines 16-63), wherein the storage pool is configured to store incremental storalgSI 
data from an incremental storage operation on a volume (col. 19, lines 36-47 - the 
storage pool comprises at least one secondary and virtual volume). 

As for claim 20, Dunham teaches the storage module as being further configured 
to allocated and de-allocate a portion of a storage volume to the backup virtual volume 
(Fig. 15, if a spare volume is available, the next virtual volume will be assigned to it - 
col. 21, lines 16-63. Note additionally Dunham teaches de-allocating volumes after 
modification access - col. 6, line 33 through col. 7, line 17). 

• H 

As for claim 21 , Dunham teaches the baseline volume as being part of the i 
storage pool (the baseline volume is contained within the secondary volume (Fig. 1 , 
element 29)). 

As for claim 22, Dunham teaches the policy management module as residing in a 
host (as per the rejection of claim 1 , supra). 

As for claim 18, Dunham teaches the incremental data comprising snapshot data 
of the primary volume (col. 5, lines 57 through col. 6, line 6 - the snapshot operation is 
performed in response to the backup operation). 
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Despite these teachings (including backup virtual volumes), Dunham fails to 
specifically teach incremental snapshots (i.e. storage) as claimed by Applicant, rather 
he teaches performing a full backup. 

Manley however discloses a system and method for asynchronous mirroring of 
snapshots at a destination using a purgatory directory and inode mapping in which 
incremental snapshots are added subsequent to the base snapshot (paragraph 0074, 
all lines). ; s| 

It would have been obvious to one of ordinary skill in the art at the time of the > 
invention for Dunham to further include Manley's asynchronous mirroring of snapshots 
into his own virtual storage system. By doing so, Dunham have a more efficient • |'M$f 
snapshot mechanism, capable of only storing and transferring data that has been 
modified, rather than performing a full backup as taught by Manley in paragraph 0015, 
all lines. 

4. Claim 14 is rejected under 35 U.S.C. 103(a) as being unpatentable over Dunham 
(US Patent 6,269,431 B1) and Manley (US PG Publication 2003/0182325 A1) as 
applied to claim 1 2 above, and in further view of Anaso et al. (US PG Publication 
2003/0191909 A1), hereinafter Anaso. 1 ^ 

As.for claim 14, though Dunham in view of Manley teach all of the limitations of *j 
claim 12, they fail to teach changing a storage capacity of the backup virtual volume as 
further comprising alerting a user of a storage over-italicization or under-utilization aw^ 
changing the storage capacity in response to user input. 
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Anaso however teaches a storage utilization monitoring system in which the 

! * 

system maintains a storage capacity table, which is used to notify the user in case of 

I H 

over or under utilization of storage capacity (paragraph 0047, all lines). • *' f \ 

It would have been obvious to one of ordinary skill in the art at the time of the 
invention for Dunham and Manley to further include Anaso's storage utilization 
monitoring system into his own system of virtual storage devices for recovery of backup 
data. By doing so, Dunham would benefit by having a means more efficiently 
monitoring storage capacity by eliminating the need for a computer itself to perform the 
monitoring process. This in turn would help Dunham's system to realize could help 
reduce system management costs incurred by system monitoring, as taught by Anaso 
(paragraph 0014, all lines). 

' . I ;i 

Response to Arguments 

5. Applicant sets forth on page 14 of the remarks (end of paragraph 0003) three , , 
generic arguments to support why Dunham and Manley allegedly do not render the 
instant claims obvious. Those three statements are as follows: 

I. "The Applicants respectfully assert that Dunham and Manley combined 
fail to teach or disclose each element of the claimed invention as required under 
35 U.S.C. § 103(a)." 

II. "The Applicants assert that there is no motivation, suggestion, or 
teaching in either Dunham or Manley to combine the references." ■ 4 

■N 

1 •! 
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III. "The Applicants also assert that both Dunham teaches away from the 
Applicants' claimed invention." 

With respect to the first argument, Applicant contends (in paragraph 0005), 
"Dunham does not teach changing the storage capacity of a virtual storage volume but 
instead teaches assigning a new virtual volume number (i.e., the next available virtual 
volume number) to the spare primary volume. Id. at col. 18, 11.27-33, col. 21, 11. 16-26? 
Fig. 1 5, steps 241 ,242. Dunham does not teach increasing storage capacity of any j 
virtual volume by adding volumes from a storage pool. See generally id. Claim 1 recites 
allocating spare storage volumes to increase the capacity of the virtual volume that !i 
stores incremental storage data, not adding a new virtual volume." 

This argument however is not persuasive, as Examiner maintains that Dunham 
does in fact clearly disclose "wherein changing the storage capacity comprises 
dynamically allocating and de-allocating a storage volume of the storage pool to the 
virtual volume in response to the change to the storage capacity" as required by the 

claim. More specifically, referring to the follow diagram illustrated by Fig. 15, elements 

i 4 

241 , 242 and 243, Dunham clearly teaches allocating a spare volume, and 
subsequently writing to the volume. Allocating and writing to a volume decreases the ' : \ 
effective amount of total capacity of that particular volume, hence the capacity has 
changed. Additionally it is worthy to note Applicant's argument that "Dunham does not 
teach increasing storage capacity of any virtual volume by adding volumes from a 
storage pool" is not persuasive, and it is not commensurate with the scope of the claim 
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limitation (i.e. lines 12-15 of claim 1), which requires simply changing the capacity via 
dynamic allocation and deallocating functions. 

Applicant additionally contends in paragraph 0006 that "Dunham does not teaqh^.^, 
de-allocating a storage volume of the storage pool of the virtual storage volume as 
recited in Claim 1. Instead, Dunham teaches de-allocating the spare storage volume on 
the primary storage where the backup data was copied when the virtual volume mapped 
to the backup data is no longer required and also releasing the virtual volume number 
and spare capacity for future use." 

This argument however is not persuasive, as Examiner maintains that Dunham 
does in fact teach "de-allocating a storage volume of the storage pool of the virtual I $ 
storage volume" as required by claim 1 . More specifically, during the backup process 1 , 

! 1 

as disclosed by Dunham in col. 6 line 33 though col. 7, line 17, once the data is written 
to the storage pool (i.e. a particular volume), that capacity of that volume is no longer f^t 
available to the pool, hence it has been deallocated. This reasoning is consistent with 
Examiner's broadest reasonable interpretation of the claim in light of Applicant's 
specification pursuant to MPEP §2111. 

Applicant concludes in paragraph 0008, "neither Dunham nor Manley teaches the 
limitations of amended Claim 1 regarding allocating and de-allocating storage volumes 
to change the storage capacity of the virtual volume storing incremental backup data 
and that amended Claim 1 is in condition for allowance." : ^ 

This argument however is not persuasive, as Examiner maintains that the | . | 
teachings of Dunham in further view of Manley disclose allocating and de-allocating of 
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the (virtual volume stored in the ) storage pool, and changing the storage capacity (the 
storage capacity must change by virtue of writing data to the pool) as per the arguments 
presented above. Further, the combined teachings of Dunham and Manley disclose an 
incremental backup (i.e. incremental snapshot) system as per the rejections presented 
supra. 

■ "l! 

With respect to the second argument, Applicant contends that there is no 
motivation to combine Dunham and Manley (as per paragraph 0003 of the remarks), 
however provides no further justification to support this assertion. Examiner is therefore 
not persuaded and maintains that it would have been obvious to one of ordinary skill in 
the art at the time of the invention for Dunham to further include Manley's asynchronous 
mirroring of snapshots into his own virtual storage system. By doing so, Dunham have 
a more efficient snapshot mechanism, capable of only storing and transferring data that 
has been modified, rather than performing a full backup as taught by Manley in 
paragraph 0015, all lines. 

With respect to the third argument, Applicant asserts, "Dunham specifically and 

I i 

exclusively teaches backing only an entire logical data structure corresponding to a 
physical storage unit even when only a file, directory, etc. has been requested for , ^ ^ 
backup." Further, "Dunham also teaches away from backing up anything less than an 
entire physical storage unit." Applicant concludes, Given the teachings of Dunham, one 
of skill in the art would b led away from any incremental backup taught by Manley or any 
other prior art. The Applicant respectfully suggest that combining Dunham with any 
other prior art that teaches an increment backup system is improper because Dunham 

i # 
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does not teach, disclose, or suggest any motivation for an incremental backup system 



and, in fact, teaches away from an incremental backup." .-ir 
This, argument however is not persuasive. Examiner maintains that it is in fact 
Manley, not Dunham that provides suggestion and motivation as to why it would have 
been obvious for Dunham to incrementally back his system up, rather than relying on 
copying the entire storage. As asserted in the previous and current rejections, it would 
have been obvious to one of ordinary skill in the art at the time of the invention for 
Dunham to further include Manley's asynchronous mirroring of snapshots into his own 
virtual storage system. By doing so, Dunham have a more efficient snapshot ! 1 1 

mechanism, capable of only storing and transferring data that has been modified, ratljeis 
than performing a full backup as taught by Manley in paragraph 0015, all lines. It would 
have been obvious to one of ordinary skill in the art to perform such a backup in viewjcif§ ' n 
Manley's teachings in order to increase Dunham's system resource efficiency (i.e. 
increase storage capacity by requiring only modified data be backed up). 
6. Applicant's arguments in paragraphs 0010 and 0011 that all remaining 
independent and dependant claims are allowable for similar reasons as set forth in 
claim 1 is not persuasive, as Examiner maintains that all pending claims remain rejected 
under 35 (JSC § 103(a) per the arguments and rejections discussed supra. 



Conclusion 



7. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1.136(a). M 
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8. A shortened statutory period for reply to this final action is set to expire THREE 

MONTHS from the mailing date of this action. In the event a first reply is filed within 

TWO MONTHS of the mailing date of this final action and the advisory action is not 

mailed until after the end of the THREE-MONTH shortened statutory period, then the 

shortened statutory period will expire on the date the advisory action is mailed, and any 1 

extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
• t -li- 
the advisory action. In no event, however, will the statutory period for reply expire later 

than SIX MONTHS from the mailing date of this final action. 

9. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Craig E. Walter whose telephone number is (571 ) 272- 
8.154. The examiner can normally be reached on 8:30a - 5:00p M-F. 

1 0. If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Hyung S. Sough can be reached on (571) 272-6799. The fax phone ( ( i 



I- Hi 



number for the organization where this application or proceeding is assigned is 571- 
273-8300. 



! 4 
M 
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1 1 . Information regarding the status of an application may be obtained from the * 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 

Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 

I -tit' 

USPTO Customer Service Representative or access to the automated information 



system, call 800-786-9199 (IN USA OR CANADA) or 571-27Z-1000. 
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